Re: [TLS] OCSP must staple

[Brian Smith <[e-mail]>]

On Thu, Jun 5, 2014 at 11:07 AM, Michael StJohns <[e-mail]>
wrote:

> I didn't realize that PHB had defined it as a transitive (i.e. if the CA
> has it, then it applies all the way down the chain) extension, rather than
> just a simple one-off application.
>

I don't think it actually is transitive. That is why I was asking it to be
changed to be transitive. I guess either way the draft should be clarified
regarding this.

Given the above, I would reject the document and suggest instead that this
> use the CertificatePolicies extension.
>

<snip>

1) Define a policy OID for TLS Features
> 2) Define a PolicyQualifier OID for a FeatureIds qualifier
> 3) Define "FeatureIds ::= SEQUENCE of TlsFeatures"
> 4) Define "TlsFeatures ::= INTEGER { feature1 (1), feature2(2), ...}
>
> This is more flexible, but seems to violate the spirit of RFC5280, section
> 4.2.1.4 - the "RECOMMENDS" items.
>

Right, we should avoid going against RFC 5280's  recommendation here, so I
don't think this is a reasonable option.

Doing it one of the above ways doesn't require modification to the cert
> path building logic (which isn't fully specified in the draft and should
> be).  The first also - mostly - doesn't require changes to code that build
> certificates which means it could enter production on the cert side much
> quicker.
>

Is it really significantly easier for CAs to add new certificate policies
compared to adding new certificate extensions? I could see how that could
be the case, but I think it would be good to hear from CAs about this.

I think one consideration is whether somebody that is operating an
externally-operated sub-CA using closed-source, slow-release-cycle software
(e.g. Microsoft's CA software) could implement the policy-based approach
without waiting for any patch/update from their vendor. If that is the
case, that would be a significant benefit of your (policy-OID-per-feature)
policy-based approach.

Cheers,
Brian