Re: [TLS] AD review of draft-ietf-tls-oob-pubkey

[Sean Turner <[e-mail]>]

On 5/14/13 4:30 AM, Bert Greevenbosch wrote:
> [Joe]  I agree, but to your point above would you want to restrict the use of an extension that could easily be extended to use a different mechanism in the future?   I think here we would probably want to add text to the document to say that this document does not cover how revocation either.
>
> "Revocation of keys is not covered by this document.  Specifications that make use of this extension need to describe if and how revocation of keys is performed.  At the time of this document's publication, OCSP does not support the revocation of raw public keys so [TLS-OCSP] and [TLS-MULTI_OCSP]  do not apply. "
>
> [Bert] I wonder if it would make sense to add some kind of a meta field as follows:
>
>        SubjectPublicKeyInfo  ::=  SEQUENCE  {
>             algorithm            AlgorithmIdentifier,
>             subjectPublicKey     BIT STRING
>             meta                 OCTET STRING
>        }
>
> This could then be used to provide meta information about the public key, e.g. information that may be needed by an out of band authentication method. The field could be ignored by default, unless the particular trust model requires differently.
>
> I guess DER encoding also allows addition of unspecified fields, but I am not sure if they will be ignored or lead to exceptions.

Please don't add the meta field there.  The idea was that the 
SubjectPublciKey might just be grabbed from a certificate and that 
field's not there in a certificate.  Further, I think the DANE 
structures require that SubjectPublicKeyInfo be as specified in RFC 5280 
(i.e., sans meta).

spt