Showing posts with label standards. Show all posts
Showing posts with label standards. Show all posts

Monday, 8 August 2011

On email address in host certificates

Every so often we get questions about email addresses in the names (distinguished names, ie DNs) of host certificates. The problem is that they are deprecated (see the last two paragraphs of section 4.1.2.6 of RFC5280), and they cause all sorts of problems with software which stringifies the DNs because there is no consistent way of doing it (or rather, there are too many consistent ways.) Arguably the software is not coded correctly, but in this case it'd be better to remove the email.

The email is there for historical reasons: when we rekey a certificate we have to give it the same name as before, so that's why it is still there. Dating back ten years or so, the original raison d'ĂȘtre was that before robot certificates, hosts would sometimes run stuff on behalf of users, ie. act as a client, and the email address was meant to give you something to contact when you read the DN in the log file.

The new policy will permit removing the email address from DNs. That's the easy bit.

The trick is to get the software to optionally (at the owner's request) remove the email address from the DN (because some people may genuinely want to keep it, for whatever reason.) Or rather, optionally keep it. The software cannot do this yet.

In fact, it'd be easier to just remove it for all host certificates, or maybe to handle those "manually" who still want to keep it, as with robots for example. If anyone out there has host certificates and depends on email being present in the DN, could you let us know via the usual channels, please? There are no known problems with removing the email address, only with keeping it, but there may of course be unknown problems - there are lots of weird and wonderful things out there.

As for timescale, it'll be ready at the latest when the new (rollover) CA certificates go live at the end of September.

Monday, 15 June 2009

Another good OGF for NGS

OGF26 in Chapel Hill, NC, US, was fairly small by OGF standards, but it was yet another productive one.

It is interesting to have both industry and academic input, because we obviously have different priorities; this has turned out to be a positive outcome of the merger between the then GGF and EGA. Also interesting now is the interaction between the OGF and OGC who themselves have large and diverse communities - I see a potential for lots of fruitful collaborations.

Apart from our very own David Wallom being made VP of e-Research, I was made Area Director for security. This is an interesting challenge which I look forward to. For one thing, there are numerous security related projects building things for the NGS, and being able to chase them about using standards - or creating them when they don't exist - will be useful. Also interestingly, I had been given a grid security shopping list by some industry contacts.
  • The Storage Resource Manager (GSM-WG) made progress with standardisation of SRM 2.2.
  • More talk about digital repositories (more about this later), and a new research group is formed (DR-RG). The iRODS folks are also involved in this (iRODS being the next generation "data grid," SRB being the previous one.)
  • "Cloud" interfaces are now being standardised, slightly unfortunately as "OCCI" (Open Cloud Computing Interface or something to that effect) which is also Oracle's C++ API. As if there were not enough XTLAs (eXtended Three Letter Acronyms).
  • Again a fair number of interoperation activities - since the NGS is not homogeneous, interoperation is relevant to us.
  • More Certification Authority stuff - a whole day of it! - of more later.
It is hard to summarise a whole conference in a few bullet points; it is maybe worth picking out a few items and looking at them in detail in some appropriate forum. As a whole I believe it is good that the NGS is engaged in standardisation and interoperation between the grids.