Re: [lamps] [Non-DoD Source] Re: Request for review of revised RFC 5759

[Michael Jenkins <[e-mail]>]

Paul,

Good point. And... grr. This is a problem we stumble over infrequently 
but painfully. You can load the US DOD roots from 
<https://iase.disa.mil/pki-pke/Pages/tools.aspx> to make it work, but we 
realize that's not acceptable.

We're working this issue and will respond in the next few days (and bump 
the draft with a corrected reference).

Thanks for the review.

On 02/20/2018 09:48 PM, Paul Hoffman wrote:
> On 31 Jan 2018, at 12:59, Michael Jenkins wrote:
>
>> The first draft updates RFC 5759, and addresses requirements for RFC 
>> 5280 compliant public-key certificates and CRLs that contain or 
>> reference algorithms in the CNSA suite. It is available at 
>> <https://www.ietf.org/internet-drafts/draft-jenkins-cnsa-cert-crl-profile-01.txt>. 
>> We would appreciate any comments you might have regarding the draft, 
>> either via the mail-list or via direct reply.
>
> This looks good on its face. However, I would argue that the reference 
> [CNSA] is a normative reference: one cannot evaluate whether the 
> requirements in the draft match the requirements in [CNSA] without 
> reading and understanding [CNSA].
>
> A big issue, however, is that [CNSA] points to:
>    https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm
> I cannot read that document on any of my browsers because the 
> certificate used for TLS is invalid in current browsers, and 
> attempting to switch to the HTTP version redirects to the insecure 
> HTTPS version.
>
> I know that this is not something that the authors can fix on their 
> own, but I would strongly object to the IETF moving this document 
> forwards as an RFC with a normative reference that no one can read 
> without making TLS changes in their browsers. Lots of US federal 
> agencies have HTTPS web sites that are readable by the general public; 
> this should be no different.
>
> --Paul Hoffman
>